Dynamic media zones systems and methods

ABSTRACT

Systems and methods are described for applying digital rights management techniques to manage zones in electronic content. In one embodiment, zones are defined in a piece of electronic content, and a license is associated with the electronic content that indicates how the zones are to be accessed or otherwise used. A digital rights management engine governs access to or other use of the zoned content in accordance with the license.

RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.12/178,543 filed Jul. 23, 2008, which claims priority from U.S.Provisional Patent Application Ser. No. 60/951,342, filed Jul. 23, 2007,both of which are hereby incorporated by reference.

COPYRIGHT AUTHORIZATION

A portion of the disclosure of this patent document contains materialwhich is subject to copyright protection. The copyright owner has noobjection to the facsimile reproduction by anyone of the patent documentor the patent disclosure, as it appears in the Patent and TrademarkOffice patent file or records, but otherwise reserves all copyrightrights whatsoever.

BACKGROUND AND SUMMARY

In modern computing systems, it is often desirable to limit access toelectronic content, services, or processing resources, or to allow onlycertain entities to perform certain actions. A variety of techniqueshave been developed or proposed to enable such control. These techniquesare often referred to as digital rights management (DRM) techniquesbecause, in general terms, their goal is to manage the rights of variousentities in digital or other electronic content, services, or resources.Systems and methods are presented herein for facilitating the managementof electronic content. It will be appreciated that these systems andmethods are novel, as are many of the components, systems, and methodsemployed therein.

In a preferred group of embodiments, systems and methods are providedthat support the description and control of different types of zones inelectronic content. For example, a zone might comprise a portion of amedia presentation that has specific attributes representing constraintsthat a media player application must obey when playing back thepresentation, such as an advertisement zone that must not be skipped, ora warning screen that must be viewed before the rest of the presentationcan be viewed.

While prior systems have attempted to require users to viewadvertisements or warnings, these systems typically hardcoded suchrequirements (and the advertisements and warnings themselves) into thesystem architecture and provided no visibility into whether suchrequirements were actually honored or how many times the warnings oradvertisements were viewed. Preferred embodiments of the inventive bodyof work described herein can be used to ameliorate some or all of thesedrawbacks, and to enable rich, flexible, policy-based controls to beassociated with the manner in which viewing requirements are enforcedand recorded, and also support the dynamic modification of suchrequirements, including, without limitation, modification of suchrequirements based on events such as the passage of time, thesatisfaction of other conditions, and/or the like. In addition,preferred embodiments of the systems and methods described herein enablethe dynamic insertion of content, such as an advertisement, into a pieceof rights-managed content, such that playback of the advertisement isgoverned in accordance with policies specified, e.g., by the author,publisher, and/or distributor of the content and/or the advertisement.Thus, preferred embodiments of the systems and methods described hereinenable the use of digital rights management techniques to support theinsertion and controlled playback or other use of specific portions of apiece of electronic content.

It should be appreciated that embodiments of the presently describedinventive body of work can be implemented in numerous ways, including asprocesses, apparatuses, systems, devices, methods, computer readablemedia, and/or as a combination thereof. Several illustrative embodimentsare described below.

BRIEF DESCRIPTION OF THE DRAWINGS

The inventive body of work will be readily understood by referring tothe following detailed description in conjunction with the accompanyingdrawings, in which:

FIG. 1 is an example of an illustrative media file annotated inaccordance with one embodiment.

FIG. 2 shows an illustrative system for managing the use of electroniccontent.

FIG. 3 shows a more detailed example of a system that could be used topractice embodiments of the inventive body of work.

FIG. 4 shows a piece of content encoded in accordance with oneembodiment.

FIG. 5 shows an illustrative data structure description of the zonesassociated with the piece of content shown in FIG. 4.

FIG. 6 shows a more detailed illustration of one embodiment of a systemfor applying digital rights management techniques to manage media zones.

FIG. 7 shows a piece of content encoded in accordance with oneembodiment.

FIG. 8 is a flowchart illustrating the governance of a piece ofelectronic content in accordance with one embodiment.

FIG. 9 is a flowchart illustrating how a license governing access to apiece of content may be enforced in one embodiment.

FIG. 10 shows a piece of content encoded in accordance with oneembodiment.

DETAILED DESCRIPTION

A detailed description of the inventive body of work is provided below.While several embodiments are described, it should be understood thatthe inventive body of work is not limited to any one embodiment, butinstead encompasses numerous alternatives, modifications, andequivalents. In addition, while numerous specific details are set forthin the following description in order to provide a thoroughunderstanding of the inventive body of work, some embodiments can bepracticed without some or all of these details. Moreover, for thepurpose of clarity, certain technical material that is known in therelated art has not been described in detail in order to avoidunnecessarily obscuring the inventive body work.

FIG. 1 shows an example of a piece of electronic content 100 thatincludes several zones (102 a, 102 b, 102 c, 102 d). For example,content 100 may comprise an entire media presentation that includes amovie and additional content items associated therewith. For example,zone 102 a may by a warning not to copy the movie without authorization,zone 102 b may be a preview of another movie, zone 102 c may be anadvertisement, and zone 102 d may be the movie itself. Content 100 mayalso include a number of markers 104 a, 104 b at which additionalcontent—sometimes referred to herein as “external zones”—can be insertedat a later time (e.g., advertisements). When content 100 is packaged inaccordance with a digital rights management system, access to or otheruse of some or all of content 100 can be governed by associated licenses(e.g., controls). In a preferred embodiment, and as described in moredetail below, these licenses can specify how the zones 102, 104 thatmake up content 100 are to be accessed or otherwise used, and what theconsequences of such access or other use are to be.

FIG. 2 shows an example of a system 200 in which content such as thatshown in FIG. 1 can be distributed and managed using a digital rightsmanagement system. In a preferred embodiment, a digital rightsmanagement system can be used such as that described in commonlyassigned, co-pending U.S. patent application Ser. No. 11/583,693,entitled Digital Rights Management Engine Systems and Methods, filedOct. 18, 2006, and published as Publication No. 2007-0180519-A1 (“the'693 application”), the contents of which are hereby incorporated byreference; however, it will be appreciated that any suitable digitalrights management system could be used in accordance with the principlesset forth herein.

As shown in FIG. 2, an entity 202 holding rights in electronic content203, packages the content for distribution and consumption by end users208 a-e (referred to collectively as “end users 208,” where referencenumeral 208 refers interchangeably to the end user or the end user'scomputing system, as will be clear from the context). For example,entity 202 may comprise a content owner, creator, or provider, such as amusician, movie studio, publishing house, software company, author,mobile service provider, Internet content download or subscriptionservice, cable or satellite television provider, the employee of acorporation, or the like, or an entity acting on behalf thereof, andcontent 203 may comprise any electronic content. For example, content203 may comprise digital video, audio, or textual content, a movie, atelevision show, a video clip, a song, a podcast, a video game, a pieceof software, an email message, a text message, a word processingdocument, a report, or any other entertainment, enterprise, or othercontent. As part of the packaging process entity 202 will typicallydefine various zones that the content will contain, such as thosedescribed in connection with FIG. 1. This may entail insertingadditional content 215 (e.g., advertisements, warnings, previews, etc.)into content 203, or may simply entail labeling portions of content 203(e.g., some or all of a movie), and/or may entail defining markers atwhich additional content (e.g., advertisements, etc.) can subsequentlybe inserted (e.g., on the fly during playback). The packaging processwill also typically entail applying any security protections dictated bythe digital rights management system being used. For example, thecontent may be secured by one or more cryptographic mechanisms such asencryption or digital signature techniques, for which a trust authority210 may be used to obtain the appropriate cryptographic keys,certificates, and/or the like.

In the example shown in FIG. 2, entity 202 uses a packaging engine 209to associate a license or other form of electronic control 206 with thepackaged content 204. License 206 is based on the policies 205 or otherwishes of entity 202, and specifies permitted and/or prohibited uses ofthe content and/or one or more conditions that must be satisfied inorder to make use of the content, or that must be satisfied as acondition or consequence of use. While FIG. 2 shows the license beingassociated with the content by entity 202, it will be appreciated thatin other embodiments such licenses could be associated and/or modifiedby another entity (e.g., a redistributor or other rightsholder). Ofparticular relevance here, the license may specify how the various zonesin the piece of content are to be handled, and whether any reportinginformation regarding access to or other use of the zones is to berecorded. For example, the license may indicate requirements such asthat a warning zone cannot be skipped, but can be fast-forwardedthrough; that after a preview is viewed once, it can be skipped onsubsequent playbacks; that previews will no longer be displayed after acertain date; that advertisements must be viewed (and can't be skippedor fast-forwarded through) if the user is not a subscriber to a premiumservice and/or has not paid more than a predefined amount for thecontent; that information about whether certain zones were skipped orfast-forwarded through must be recorded; that information regarding thenumber of times a particular zone has been viewed must be recorded;and/or virtually any other sort of requirement that the digital rightsmanagement system is capable of enforcing.

As shown in FIG. 2, the packaged content 204 and associated license (orlicenses) 206 are distributed to end users via any suitable mechanism(e.g., via download or stream over a network 212 like the Internet, alocal area network, a wireless network, a virtual private network 207, awide area network, and/or the like; via recordable media 216 such as acompact disc (CD), digital versatile disk (DVD), a flash memory card(e.g., a Secure Digital (SD) card), and/or the like; via cable,satellite, broadcast, or cellular communication 214; and/or the like),where the content is rendered for the user 208 in accordance with theterms of the associated license. As shown in FIG. 2, packaged content204 can be delivered to the user together with license 206 in a singlepackage or transmission 213, or in separate packages or transmissionsreceived from the same or different sources.

Typically, the license terms will be enforced by a digital rightsmanagement engine running on the user's system 208. The end user'ssystem (e.g., a personal computer 208 e, a mobile telephone 208 a, atelevision and/or television set-top box 208 c, a portable audio and/orvideo player 208 d, an electronic book reader, a gaming system, a persondigital assistant, and/or other electronic device) will typicallycontain application software 216, hardware, and/or special-purpose logicthat is operable to retrieve and render the content. The user's digitalrights management engine 218 will evaluate the license 206 associatedwith the packaged content 204 and enforce the terms thereof (and/orenable application 216 to enforce such terms), such as by selectivelygranting the user access to the content only if permitted by thelicense. Digital rights management engine 218 may be structurally orfunctionally integrated with application 216, or may comprise a separatepiece of software and/or hardware. Alternatively, or in addition, auser's system, such as system 208 c, may communicate with a remotesystem, such as system 208 b, (e.g., a server, another device in theuser's network of devices, such as a personal computer or televisionset-top box, and/or the like) that uses a digital rights managementengine to make a determination 220 as to whether to grant the useraccess to content previously obtained or requested by the user.

The digital rights management engine, and/or other software on theuser's system, or in remote communication therewith, may also recordinformation regarding the user's access to or other use of the protectedcontent. In some embodiments, some or all of this information might becommunicated to a remote party (e.g., a clearinghouse 222, the contentcreator, owner, or provider 202, the user's manager, an entity acting onbehalf thereof, and/or the like), e.g., for use in allocating revenue(such as royalties, advertisement-based revenue, etc.), determining userpreferences, enforcing system policies (e.g., monitoring how and whenconfidential information is used), and/or the like. It will beappreciated that while FIG. 2 shows an illustrative DRM architecture anda set of illustrative relationships, the systems and methods describedherein can be practiced in any suitable context, and thus it will beappreciated that FIG. 2 is provided for purposes of illustration andexplanation, not for purposes of limitation.

FIG. 3 shows a more detailed example of one possible embodiment of asystem 300 that could be used to practice embodiments of the inventivebody of work. For example, system 300 might comprise an embodiment of anend user's device 208, a content provider's device 202, and/or the like.For example, system 300 may comprise a general-purpose computing devicesuch as a personal computer 208 e or network server 207, or aspecialized computing device such as a cellular telephone 208 a,personal digital assistant, portable audio or video player 208 d,television set-top box, kiosk, gaming system, or the like. System 300will typically include a processor 302, memory 304, a user interface306, a port 307 for accepting removable memory 308, a network interface310, and one or more buses 312 for connecting the aforementionedelements. The operation of system 300 will typically be controlled byprocessor 302 operating under the guidance of programs stored in memory304 (and/or other computer-readable media, such as removable memory308). Memory 304 will generally include both high-speed random-accessmemory (RAM) and non-volatile memory such as a magnetic disk and/orflash EEPROM. Some portions of memory 304 may be restricted, such thatthey cannot be read from or written to by other components of the system300. Port 307 may comprise a disk drive or memory slot for acceptingremovable memory 308 such as diskettes, CD-ROMs, DVDs, memory cards, SDcards, other magnetic or optical media, and/or the like. Networkinterface 310 is typically operable to provide a connection betweensystem 300 and other computing devices (and/or networks of computingdevices) via a network 320 such as the Internet or an intranet (e.g., aLAN, WAN, VPN, etc.), and may employ one or more communicationstechnologies to physically make such a connection (e.g., wireless,Ethernet, and/or the like). In some embodiments, system 300 might alsoinclude a processing unit 303 that is protected from tampering by a userof system 300 or other entities. Such a secure processing unit can helpenhance the security of sensitive operations such as key management,signature verification, and other aspects of the digital rightsmanagement process.

As shown in FIG. 3, memory 304 of computing device 300 may include avariety of programs or modules for controlling the operation ofcomputing device 300. For example, memory 304 will typically include anoperating system 321 for managing the execution of applications,peripherals, and the like; a host application 330 for renderingprotected electronic content; and a DRM engine 332 for implementing someor all of the rights management functionality described herein. Asdescribed elsewhere herein and in the '693 application, DRM engine 332may comprise, interoperate with, and/or control a variety of othermodules, such as a virtual machine for executing control programs, astate database 324 for storing state information, and/or one or morecryptographic modules 326 for performing cryptographic operations suchas encrypting and/or decrypting content, computing hash functions andmessage authentication codes, evaluating digital signatures, and/or thelike. Memory 304 will also typically include protected content 328 andassociated licenses 329, and may also include zones 327 that are to bedynamically inserted into the content, as well as cryptographic keys,certificates, and the like (not shown).

One of ordinary skill in the art will appreciate that the systems andmethods described herein can be practiced with computing devices similaror identical to that illustrated in FIG. 3, or with virtually any othersuitable computing device, including computing devices that do notpossess some of the components shown in FIG. 3 and/or computing devicesthat possess other components that are not shown. Thus it should beappreciated that FIG. 3 is provided for purposes of illustration and notlimitation.

The discussion herein focuses primarily on the enforcement of licenserestrictions relating to media zones, with the assumption that if theDRM engine and host application operate as intended, the terms of thelicense will be enforced. In practical applications of the systems andmethods described herein, protection of the DRM engine and/or theenvironment in which the DRM engine runs (e.g., the applications andhardware with which it interacts) from malicious tampering ormodification can be accomplished using any suitable combination ofsecurity techniques. For example, cryptographic mechanisms such asencryption, digital signatures, digital certificates, messageauthentication codes, and the like can be employed, e.g., as describedin the '693 application, to protect the DRM engine, host application,and/or other system software or hardware from tampering and/or otherattack, as could structural and/or tactical security measures such assoftware obfuscation, self-checking, customization, watermarking,anti-debugging, and/or other mechanisms. Representative examples of suchtechniques can be found, for example, in U.S. Pat. No. 6,668,325 B1,Obfuscation Techniques for Enhancing Software Security, and in commonlyassigned U.S. patent application Ser. No. 11/102,306, published asUS-2005-0183072-A1, and entitled Software Self-Defense Systems andMethods; U.S. patent application Ser. No. 11/737,428, published asUS-2008-0028474-A1, and entitled Systems and Methods for WatermarkingSoftware and Other Media; U.S. patent application Ser. No. 10/172,682,published as US-2003-0023856-A1, and entitled Software Self-CheckingSystems and Methods; U.S. patent application Ser. No. 11/338,187,published as US-2006-0123249-A1, and entitled Trusted Storage Systemsand Methods; and U.S. Pat. No. 7,124,170 B1, Secure Processing UnitSystems and Methods, each of which is hereby incorporated by referencein its entirety. Alternatively, or in addition, physical securitytechniques (e.g., the use of relatively inaccessible memory, secureprocessors, secure memory management units, hardware-protected operatingsystem modes, and/or the like) can be used to further enhance security.Yet another form of security can be provided by the institutional designand operation of the system, and by the legal and social regulation ofthe participants therein. For example, entities in the system may berequired to contractually agree to adhere to system specifications andrequirements, may need to submit to a certification process during whichthe entity's compliance with system requirements could be verified,and/or the like. For example, a device or application may be required toimplement the DRM engine in a way that is compatible with otherimplementations in the environment, and/or be required to provide acertain type or level of tamper resistance or other security. Digitalcertificates could be issued that attested to a device's or otherentity's compliance with such requirements, and these certificates couldbe verified before allowing the device or entity to participate in thesystem, or as a condition of allowing continuing access. Such securitytechniques will be well-known to one of ordinary skill in the art, andit will be appreciated that any suitable combination of some, none, orall of these techniques could be used depending on desired level ofprotection and/or the details of the particular application at hand. Itwill also be appreciated that while certain security mechanisms aredescribed herein in connection with certain embodiments, use of thesetechniques is not required in all embodiments. Additional, non-limitinginformation on security techniques that can be used in connection withthe inventive body of work is set forth in the '693 application.

A more detailed description of the application of digital rightsmanagement techniques to support the definition and enforcement ofdynamic media (or other content) zones is provided below. In a preferredgroup of embodiments, a DRM system employing a DRM engine such as thatdescribed in the '693 application (sometimes referred to herein or inthe '693 application as the “Octopus” DRM engine) is used. Although thefollowing description of example embodiments will at times refer to sucha DRM engine, it will be appreciated that the concepts illustrated inthis description could be readily applied in the context of a differenttype of DRM system.

FIG. 4 shows a piece of content 400 comprised of a variety of zones, andFIG. 5 shows how these zones may be defined in accordance with oneembodiment. As shown in FIG. 4, content 400 includes a zone 402 thatcontains a warning screen, a zone 404 that contains the first part of amovie, and a zone 406 that contains the second part of a movie. Inaddition, as shown in FIG. 4, it is desired to insert a zone comprisinga preview 408 and a zone comprising an advertisement 410 into content400 at the locations indicated. It may also be desirable to treat theentire piece of content 400 as a zone 416, and to treat the warning, thepreview, and the first part of the movie as a zone 412, and theadvertisement and the second part of the movie as another zone 414.

FIG. 5 shows a zone map 500 for defining and describing the zones shownin FIG. 4. The zones defined in FIG. 5 are spans of the media stream 400shown in FIG. 4, and are bounded by two points in that stream. Eachpoint in the points array 504 contains a reference to a random accesspoint in the media stream (e.g., a sample, or access unit, in a mediaformat derived from the ISO Base Media Format) at which a zone stops orstarts. Internal zones 506 are indicated by a start point 508 and an endpoint 510 in the media stream. For example, zone 402 (i.e., the warningscreen) ranges from access unit 0 to access unit 30. External zones 512are indicated by a point 514 in the media stream where a portion ofanother media stream (e.g., preview 408 or advertisement 410) is to bespliced. In the embodiment shown in FIG. 5, zone map 500 also has asignature 502 that prevents zone map 500 from being modified by entitiesthat do not have knowledge of a specific key.

In one embodiment, zone identifiers 516 are used to identify each zone.Zone identifiers allow an application to locate the appropriate mediazone when signaled, e.g., in a DRM license. In one embodiment, zoneidentifiers 516 are local to a specific content item, and the ZoneMapKeythat is used to sign the zone map ties the zones to specific content. Ina preferred embodiment, the ZoneMapKey comprises a hash of the contentencryption key. In this way, the ZoneMapKey is essentially uniquely tiedto the content, yet the actual content key need not be disclosed to thecreator of the zone map, who may not be the same as the entityresponsible for creating or maintaining the content keys. This can beespecially useful in the case of the zone maps for external zones, suchas an external zone containing an advertisement created and/or providedindependently of the content into which it is to be inserted, since thecontent creator may not trust such an independent entity with thecontent decryption key, yet it would still typically be important toprotect against unauthorized substitution of different content for theintended advertisement. By signing the zone map with a hash of thecontent decryption key, a strong linkage is created between the zonesand the associated content, without compromising the secrecy of thecontent decryption key.

In some embodiments there may be more than one zone with the sameidentifier in a zone map, and there may be more than one zone mapcontaining zones with the same zone identifier. In this case, any validzone can be used. The possibility of having more than one zone with thesame identifier allows for models where multiple different media streamsfor a zone are delivered to a player application that then chooses oneof the valid zones when rendering a media presentation. Any suitablemechanism can be used by an application to choose between multiple zoneswith the same identifier.

As shown in FIG. 5, the zone map may identify a digest algorithm 520 forsome zones, and a value 522 of the digest for each such zone. In oneembodiment, when the media player plays a zone that has digestalgorithm, it computes the zone digest as the zone is being played. Whenthe zone has been completely played, it compares the value of thecomputed digest with the value contained in the zone map for that zone,and, if the values are not equal (e.g., because the zone is not intact),stops any further playback of the presentation.

TABLE 0 shows a more detailed illustration of the abstract data typesthat make up a zone map such as that shown in FIG. 5 in one preferredembodiment:

TABLE 0 ZonePoint: {   accessUnitReference: <media format dependent> }InternalZoneInfo: {   fromPoint: integer   toPoint: integer   id:integer   attributes: integer   mediaDigestAlgorithm: integer  mediaDigestValue: byte array   meteringTag: string } ExternalZoneInfo:{   splicePoint: integer   id: integer } ZoneMap: {   points: array ofZonePoint   internalZones: array of InternalZoneInfo   externalZones:array of ExternalZoneInfo   signature: {     signatureAlgorithm: integer    signatureValue: byte array   } }

Where:

“accessUnitReference” is a reference to, or identifier of, a positionin, or access unit of, the media.

“fromPoint” refers to the location in the “points” array of a“ZonePoint” corresponding to the start of a zone.

“toPoint” refers to the location in the “points” array of a “ZonePoint”corresponding to the end of a zone.

“splicePoint” refers to the location in the “points” array of a“ZonePoint” corresponding to the location in the media at which a zoneis to be spliced.

“id” is an identifier for a zone.

“attributes” refers to a bit vector equal to a combination of zero ormore flags. An example of one such flag is shown below; however, it willbe appreciated that any suitable flag or flags could be used:

Name Value Description INSERTED 1 If this flag is set, the zone to whichit corresponds represents a portion of the presentation that has beeninserted in the main presentation (such as an advertisement) and may beskipped by the player unless otherwise required (e.g., by anobligation).

“mediaDigestAlgorithm” identifies the digest algorithm used to computethe mediaDigestValue field. In one embodiment, the following algorithmidentifiers are defined:

Name Value Description NONE 0 The mediaDigestValue bytes array is empty(e.g., set to 0) SHA1 1 The bytes of the mediaDigestValue are obtainedby computing the SHA-1 hash of the media byte stream.

“mediaDigestValue” is a media-dependent digest of the media samples thatare part of the zone.

“meteringTag” is a string used as a tag for reporting zone playbackmetering (as described in more detail below).

“points” refers to an array of one or more ZonePoint values.

“internalZones” is an array of one or more InternalZoneInfo records.

“external Zones” is an array of one or more ExternalZoneInfo records.

“signature” refers to a keyed-MAC signature of the points,internalZones, and externalZones arrays. In one embodiment, the MACalgorithm and key are specified by the signatureAlgorithm field.

“signatureAlgorithm” is an identifier of the signature algorithm used tocompute the signatureValue field. For example, in one embodiment thefollowing algorithm identifier is defined:

Name Value Description HMAC_SHA1_HMK 0 The signature value is obtainedusing HMAC using the SHA-1 hash function. The signature key is obtainedby taking the first 16 bytes of the SHA-1 hash of the byte arrayconsisting of the 4 constant bytes 0x4d, 0x44, 0x4d, and 0x5a followedby the bytes of the ZoneMapKey.

signatureValue is the value of the signature specified by thesignatureAlgorithm field.

FIG. 6 is a more detailed illustration of a system 600 that uses a DRMengine 601 to manage playback or other rendering of media zones such asthose defined in FIG. 5 for a file 605 containing a piece of content 607such as shown in FIG. 4. As shown in FIG. 6, in a preferred embodiment,a zone map 602 such as that illustrated in FIG. 5 or TABLE 0 is includedwithin the file 605 containing the piece of content 607 containing zonesand/or zone markings, which is then packaged into a format required bythe DRM engine and content rendering system being employed. For example,content 607 may comprise an mp4 audio-visual file, packaged inaccordance with the DRM techniques described in the '693 application. Asshown in FIG. 6, a license 608 is associated with the content file 605,the license 608 specifying how access to or other use of content 607 isto be governed, and, of particular relevance here, the manner in whichthe various zones defined in the content's zone map 602 are to begoverned.

FIG. 6 also shows a number of content items 604 a, 604 b, 606 a, 606 b,606 c that can be spliced into content 607 at the external zonelocations identified in the zone map 602. As previously indicated, inone embodiment external zones referenced in a zone map are zones forwhich the associated media is not in the same file or container as themedia associated with that zone map. External zones allow the media fora zone to be delivered or packaged separately from the main mediapresentation in which they will be rendered. As shown in FIG. 6, in oneembodiment, when a zone map contains references to external zones, themedia 604, 606 with the content for each of those zones has anassociated zone map with its own internal zone descriptions. In oneembodiment, when more than one zone is spliced at the same point, theplayback order is the order in which the zones appear in theexternalZones array.

As shown in FIG. 6, multiple external zones with the same zone id can bedelivered to the user 612. In the example shown in FIG. 6, two differentpreviews 604 a and 604 b having the same zone identifier are deliveredto the user, as are three advertisements 606 a, 606 b, 606 c having thesame zone identifier. During playback, application 609 and/or DRM engine601 can select which of these external zones is actually spliced intothe content. This selection can be performed in any suitable manner,based on any suitable criteria. For example, a new preview could bedelivered to the user periodically, and the choice of which preview todisplay could be based on the relative age of the previews (e.g., selectthe most recently received preview). Alternatively, or in addition, thechoice of which preview to display could be based on the content of thepreviews (e.g., which preview is most similar to the movie 607 containedin file 605), a determination regarding which preview is most likely toappeal to the user based on previously collected demographic or userpreference data, random selection, or a combination of these or anyother suitable factors. Because the external zones are not embedded incontent 607, the same external zone can also be spliced into anotherpiece of content that references the external zone's id. In addition,because external zones contain their own zone maps (and, in someembodiments, may have their own licenses associated therewith), a givenexternal zone may itself reference another external zone that needs tobe incorporated into the given external zone during playback.

As previously indicated, DRM engine 601 controls access to or other useof content 607 in accordance with license 608. In particular, DRM engine601 enforces any license restrictions relating to the zones identifiedin zone map 602. It will be appreciated that the license can express anysuitable restrictions, conditions, or consequences, limited only by thecapabilities of the DRM system. For example, without limitation, alicense governing the content 400 shown in FIG. 4 may require that thewarning screen be viewed the first time the movie is played; that thepreview be viewed if it has not been viewed in the last 7 days, but onlyuntil a fixed date; that the advertisement be viewed if the user is nota subscriber to a premium service; that the user cannot fast-forwardthrough the advertisement or the preview; that information regarding theplayback of various zones be recorded; and/or the like.

In the context of a DRM system such as that described in the '693application, the expression and enforcement of such conditions mayentail the use of one or more callbacks and/or obligations in thecontrol programs that comprise the license. For example, in oneembodiment, a control program may include a MediaZones obligation in theextended status block (“ESB”) returned by the “Check” and/or “Perform”methods of a playback-related action (e.g., “Play”).

In one embodiment, the following constraint may be included in theObligations container of an ESB:

Name Type Description MediaZones ValueList One or more ZoneInfo records,where each ZoneInfo record is a ValueList with, e.g., the followingvalues: Type Description Integer Zone Id equal to the ‘id’ field of oneof the zones in the media's Zone Description Table. Integer Zone typeidentifier Integer Bit-vector of zero or more OR'ed flag values.Examples of possible flag values are defined below.

The following are examples of ZoneInfo flag values in one embodiment:

Name Value Description METER 1 If there is a metering obligation forthis content, the application also logs a metering event when this zonehas been played. INCLUDE_SPLICE 2 If this flag is set the span of mediainside this zone includes the media in the zones spliced at its ‘end’point, if any. If this flag is not set, the span of media inside thiszone does not include the zone(s) spliced at its ‘end’ point.

In one embodiment, the following ZoneTypes are defined:

Name Identifier Description NOSKIP 0 In one embodiment, the playerapplication must not automatically skip this zone; the zone must beplayed as an integral part of the presentation. MAGNETIC 1 In oneembodiment, if the player application attempts to seek inside a magneticzone from a playback position outside the zone, then the playback mustbegin at the ‘fromPoint’ point of the magnetic zone. STICKY 2 In oneembodiment, if the player enters a sticky zone, it must disable theability to fast-forward or to skip the sticky zone until the playbackposition is outside the zone.

In one embodiment, to comply with a MediaZones obligation, a playerapplication must locate at least one valid InternalZoneInfo entry foreach of the zones identifiers specified in the ZoneInfo records of theobligation. A valid entry is an entry contained in a zone map for whichthe signature is valid.

It is possible that in some embodiments the zones described in theMediaZones list may overlap. Also, the same zone may be included morethan once with different zone types, in which case that zone has thecombined properties of all those types. In one embodiment, when themedia player application attempts to seek to a position that is insidemore than one magnetic zone, the playback must begin at the earliest‘fromPoint’ of all those zones.

A Control may also include an OnZoneCompleted callback notice in the ESBreturned by the ‘Check’ and/or ‘Perform’ methods of a playback-relatedaction (such as ‘Play’). For example:

Name Type Description OnZoneCompleted ValueList In one embodiment, thehost application must callback when the specified zone has beencompletely played (unless the zone is found not to be intact, asdescribed above). The values in the ValueList are: Type DescriptionInteger Zone Id equal to the ‘id’ field of one of the zones in themedia's zone map Callback Routine to call back, and associated cookie.

In one embodiment, the key—sometimes referred to herein as the“ZoneMapKey”—that is used to bind the zone maps to a specific mediacontent item is one of the content keys used to encrypt the content thatis being played and for which the license's control has returned an ESBwith a MediaZones obligation. In one embodiment, when there is more thanone content key (for example when playing media from a container wherethe audio and video streams are encrypted with different content keys),the ZoneMapKey can be selected as follows: (a) for audio-only media, theZoneMapKey is the content key used to encrypt the audio stream; and (b)for video-only or audio/video media, the ZoneMapKey is the content keyused to encrypt the video stream.

In one embodiment, when playing content with a metering obligation, if azone has completely been played and the METERING flag is set for thatzone in the MediaZones obligation, the player application logs thatevent. In one embodiment, when reporting that event in metering data tothe metering service, the entry corresponding to that event is reportedin one or more event records, and the record(s) only include the “stop”time, omitting the “start” time. In one embodiment, the logical id forthe metering record is the string obtained by concatenating the logicalid of the metering obligation, the character ‘#’, and the meteringTagfield for that zone. In one embodiment, if the content does not have ametering obligation, a player application ignores any METERING flag, andif the content has a metering obligation that is not marked as CRITICAL,the player application may ignore the METERING flag.

EXAMPLES

FIG. 7 shows an example of a media presentation 700. In the exampleshown in FIG. 7, media presentation 700 starts with an “FBI Warning”screen 702 that must be viewed before the rest of presentation 704unless warning screen 702 has already been viewed in the past 30 days.In one embodiment, the zone map for presentation 700 would contain twozones. The warning zone 702 spans access unit 0 to access unit 189. Themovie zone 701 spans access unit 0 to access unit 2876.

FIG. 8 is a flowchart illustrating how the viewing of a piece of contentsuch as presentation 700 in FIG. 7 would be handled in one embodiment.As shown in FIG. 8, when a request to play the presentation is received(802), a determination is made as to whether the warning screen 702 hadbeen previously viewed (or played) within the last 30 days (804). Forexample, a record of when the zone containing the warning screen hadbeen viewed last could be maintained in a local (or remote) database,and the data retrieved from the database could be compared to thecurrent time in order to determine whether 30 days had elapsed since thewarning screen was last viewed. As shown in FIG. 8, if the warningscreen had been viewed in the last 30 days (i.e., a “no” exit from block804), then the presentation would begin playing at zone 704 (i.e., thezone 702 containing the warning screen would be skipped) (806). If thewarning screen has not been viewed in the last 30 days (i.e., a “yes”exit from block 804), then the presentation would begin by playing zone702 (i.e., the warning screen) (808). Once zone 702 has finishedplaying, the database can be updated to indicate that the warning screenhas just been viewed (810), and playback of the presentation cancontinue to zone 704 (806).

In the illustration shown in FIG. 7, zone 702 has been assigned a“sticky” attribute and the entire presentation has been assigned a“magnetic” attribute. These attributes can be used to preventcircumvention of the requirement that the warning screen (zone 702) beviewed if it has not been viewed in the previous 30 days. In particular,if the warning has not been viewed in the previous 30 days, the DRMengine and/or the player software or hardware will prevent the user frominitiating playback at zone 704 (i.e., after the warning). Because thepresentation has the “magnetic” attribute, playback of the presentationwill commence at the start (i.e., at access unit 0). In addition,because zone 702 has been assigned the “sticky” attribute, thefast-forward and seek features of the player software or hardware willbe disabled while this zone is being rendered, thus preventing the userfrom skipping or fast-forwarding through the warning. However, once thewarning zone has been viewed, the user will once again be able tofast-forward and skip to arbitrary locations in the presentation, sincethe DRM engine will not enforce the sticky or magnetic properties againuntil another 30 days has elapsed, and an obligation to view the warningonce again arises. It will be appreciated that the zones shown in FIG. 7are for purposes of illustration only, and that content creators candefine any suitable zones and viewing requirements.

FIG. 9 illustrates the application of zone-related obligations in thecontext of a piece of content such as that shown in FIG. 7. As shown inFIG. 9, when a request to play the content is received (900), adetermination is made as to whether any zone-related obligations exist(902). For example, if a DRM engine such as that described in the '693application is used, the perform method of the play action would returnan extended status block describing any applicable obligations. If nozone-related obligations exist (i.e., a “no” exit from block 902), thenplayback of the presentation proceeds with the omission of any internal(or external) zones that may have been inserted (903). If, on the otherhand, one or more zone-related obligations exist (i.e., a “yes” exitfrom block 902), then, for the requested access unit of thepresentation, a determination is made as to whether it is part of a newzone for which obligations exist (referred to in FIG. 9 as an “active”zone) (906). For example, a determination could be made as to whetherthe previously accessed unit (if any) was in the same zone as thecurrently requested access unit. If the requested access unit is not ina new zone (i.e., a “no” exit from block 906), then playback of theaccess unit is permitted (908). However, if the requested access unit isin a new zone (i.e., a “yes” exit from block 906), then a determinationis made as to whether the new zone is magnetic (910), and, if the newzone is magnetic (i.e., a “yes” exit from block 910), then the currentlyrequested access unit is replaced with the first access unit in thatzone (or zones). Enforcement of any other obligations relevant to thenew zone are also initiated (914). For example, if the zone is labeled“no skip,” then the seek controls on the player software and/or hardwareare disabled, and if the zone is labeled “sticky,” then both the seekand the fast-forward controls are disabled before playing the accessunit.

In the example algorithm shown in FIG. 9, once an access unit has beenplayed (908), a determination is made as to whether that access unit wasthe last access unit in an active zone (i.e., whether an active zone wascompleted)(916). If a zone was completed (i.e., a “yes” exit from block916), then, if there is a related callback (920), that callback isexecuted, and the set of relevant obligations is updated (e.g., certainobligations can be removed, updated, or imposed). If no more obligationsare active (i.e., a “no” exit from block 922, then playback of thecontent can continue without any internal (or external) zones that mayhave been inserted (903). Otherwise, the next access unit is retrieved(918), and the process described above is repeated until playback isstopped (e.g., the user presses or selects “stop” on the player).

It will be appreciated that the example algorithm shown in FIG. 9 hasbeen provided for purposes of illustration, and not limitation, and thatenforcement of zone-related obligations could be performed in anysuitable manner. For example, some of the steps shown in FIG. 9 could beperformed in a different order, concurrently with other steps, oromitted entirely.

Applying the algorithm shown in FIG. 9 to the presentation 700 shown inFIG. 7, if the user attempts to start playback at access unit 190 (i.e.,immediately after the warning screen), and the warning screen had notbeen viewed in the last 30 days (in which case, the magnetic and stickyobligations would be active), the DRM engine and/or application wouldforce playback to begin at access unit 0, since access unit 190 is partof a magnetic zone (i.e., the zone comprising the entire presentation),and access unit 0 is the start of that magnetic zone. In addition, theapplication's seek and fast forward controls would be disabled sinceaccess unit 0 is part of a sticky zone (i.e., the zone comprising thewarning screen). Similarly, if the user attempted to start playback ataccess unit 188 (i.e., immediately before the end of the warningscreen), the DRM engine and/or application would force playback to beginat access unit 0, since access unit 188 is part of a magnetic zone(i.e., the zone comprising the entire presentation), and access unit 0is the start of that magnetic zone. Once access unit 189 was rendered(i.e., the last access unit in zone 702), then a callback would be madethat would deactivate the obligations associated with zones 702 and 701,and the presentation could be played without viewing the warning screen,and fast-forwarding and seeking within the presentation would bere-enabled. If the user stops the presentation then restarts it within30 days, no obligations would be active (since the records maintained bythe DRM engine would indicate that 30 days had not elapsed since thewarning was last viewed), and the presentation could be played withoutviewing the warning screen.

An illustrative embodiment of a zone map data structure for thepresentation shown in FIG. 7 is shown below in TABLE 1.

TABLE 1 ZoneMap: {  points: [AU-0, AU-189, AU-2876]   internalZones: [  {    fromPoint=0,    toPoint=1,    mediaDigestAlgorithm=1,   mediaDigest=[...],    id=702,    attributes=1   },   {   fromPoint=0,    toPoint=2,    mediaDigestAlgorithm=1,   mediaDigest=[...],    id=704,    attributes=0   },  ]  externalZones:[ ]  signature: {    signatureAlgorithm=0,    signatureValue=[...]  }

As shown in TABLE 1, the zone map contains 3 points and two zones. Thewarning zone spans points 0 through 1 (i.e., access units 0 through 189)and has an attribute value of 1, which means it is an inserted zone inthis illustrative embodiment. This indicates to a player that if thereare not zone obligations returned by the Perform method of the Playaction, it is ok to skip this zone and start directly at access unit190. The movie zone spans zone points 0 through 2 (i.e., access units 0through 2876) and has no attribute flags set.

Illustrative pseudo-code for a control that implements the functionalitydescribed in connection with FIG. 7 and TABLE 1 is shown in TABLE 2,below:

TABLE 2 ESB-1 = {  ACTION_GRANTED  Obligations:   MediaZones: [[702,STICKY], [704, MAGNETIC]]  Callbacks:   OnZoneCompleted: [702, (RESET,ZoneCallback, 0)] } ESB-2 = {  ACTION_GRANTED }Control.Actions.Play.Perform: lastViewed =GetHostObject(/Octopus/SeaShell/Databases/Marlin/ACME/Zones/movie-0007-warning/lastViewed) if now-lastViewed > 30 days then:   returnESB-1 // the zone is magnetic else:   return ESB-2 // you can skip thewarning ZoneCallback: now = GetTrustedTime( )SetHostObject(/Octopus/SeaShell/Databases/Marlin/ACME/Zones/movie-0007-warning/lastViewed, now) return ESB-2 // you can now skip thewarning

As shown in TABLE 2, when the control is initiated, data is retrievedfrom the DRM system's state database regarding the last time that thewarning was viewed. This is compared to the current time (i.e., “now”),and if the difference is greater than 30 days, an extended status blockis returned (i.e., ESB-1) that grants the request to play the content,but imposes obligations on the warning zone (i.e., zone 702) and theentire content (i.e., zone 704) that effectively force the warning to beviewed before the rest of the movie can be viewed. A callback is alsoincluded that is initiated when viewing of the warning zone iscompleted. The callback stores the current time in the DRM system'sstate database as the time at which the warning was last viewed, andreturns an extended status block (i.e., ESB-2) that simply grantsplayback of the movie without imposing any obligations. Thus, once thewarning has been viewed and the callback has been executed, the warningzone will not be rendered and the magnetic zone obligation on the moviewill not be enforced for another 30 days.

FIG. 10 shows an example encoding of a presentation 1000 where it isdesired to allow users who have paid for the presentation to view itwithout advertisements (it will be appreciated that any other conditionor combination of conditions that the DRM engine and/or the applicationis capable of evaluating could be used instead), while requiring userswho have not paid for the presentation to view advertisements. As shownin FIG. 10, presentation 1000 could be divided into two zones: a zone1004 ranging from access unit 900 to access unit 950 corresponding to aninserted advertisement; and a zone 1010 ranging from access unit 900 toaccess unit 2300 comprising both the advertisement 1004 and the secondpart of the movie 1008. The advertisement zone 1004 is associated with a“no skip” obligation, and the zone 1010 comprising the advertisement1004 and the second part of the movie is associated with a magneticobligation.

When a request to play the second part of the presentation is received,a determination is made as to whether the user has paid for thepresentation. This determination could be made, for example, byretrieving data from the DRM engine's database, or by evaluating whethera certain node (such as a subscription node) is reachable from theplayer's node. If the user has paid for the presentation, then noobligations are returned by the perform method of the control program'splay action, and the advertisement is automatically skipped when thepresentation is viewed. However, if the user has not paid for thepresentation, then the sticky and magnetic obligations illustrated inFIG. 10 are activated, and the user must view the advertisement in orderto view the second part of the movie, and is not allowed to skip throughthe advertisement. For example, if the user attempts to start playbackat access unit 951, the player will force playback to actually start ataccess unit 900, since the zone including access unit 951 is magnetic.Once the advertisement has been viewed, the user can skip within thezone comprising the advertisement and the second part of the movie, butif the user returns to the first part of the movie 1002 and thenattempts to jump back to the second part 1008, he will, in this example,need to view the advertisement 1004 once again (or, if the advertisementis an external zone, any advertisement with the same id).

Illustrative pseudo-code for a control (such as that described in the'693 application) that implements the functionality described inconnection with FIG. 10 is shown in TABLE 3, below:

TABLE 3 ESB-1 = {  ACTION_GRANTED  Obligations:   MediaZones: [[1004,NO_SKIP], [1010, MAGNETIC]] } ESB-2 = {  ACTION_GRANTED }Control.Actions.Play.Perform: if (IsNodeReachable(“MovieSubscription”))then:    return ESB-2 // subscribers don't need to view the ads else:   return ESB-1 // the zone is magnetic and the ad can't be skipped

As shown in TABLE 3, when the control is initiated, a determination ismade as to whether the user is a subscriber to a movie service. Asdescribed in more detail in the '693 application, this is done bedetermining whether a node representing the subscription (i.e.,“MovieSubscription,” in this example) is reachable from the player'snode. If the subscription node is reachable, then the user is determinedto be a paying subscriber, and an extended status block is returned(i.e., ESB-2) that grants the request to play the content withoutimposing any obligations. However, if the subscription node is notreachable, then an extended status block is returned (i.e., ESB-1) thatgrants the request to play the content but imposes obligations on theadvertisement zone (i.e., zone 1004) and the zone comprising theadvertisement and the second part of the movie (i.e., zone 1010) thateffectively forces the advertisement to be viewed before viewing thesecond part of the movie.

It will be appreciated that the complete definition of media zonestypically entails the use of precise positioning information withinmedia presentations, thus requiring some media format-specific elements.For purposes of explanation and clarity, abstract data structures andelements common to many media formats have been described herein. Forpurposes of illustration, specific ways of representing and embeddingthese data structures and elements into certain, illustrative mediaformats are described in the following appendices. One of ordinary skillin the art will appreciate, however, that the abstract data typesdescribed herein can be readily mapped onto other media formats as well.

Appendix A—ISO Base Media File Format Mapping

In one embodiment, when defining zone points for media derived from theISO Base Media File Format (see, e.g., ISO/IEC 14496-12:2003:Information Technology—Coding of Audio-Visual Objects—Part 12: ISO BaseMedia File Format), the accessUnitReference field of the ZonePointstructure is an IsoMediaAccessUnit for sample-based formats, or anIsoMediaByteOffset for box-based formats (such as OMA DCF). The notationbelow is in the syntax description language (SDL) defined in ISO/IEC14496-1:2004, Subpart 3: Information Technology—Coding of Audio-VisualObjects.

IsoMediaAccessUnit: {   sample: integer } sample: an integer equal tobinary sample number for the media track to which the zone corresponds.IsoMediaByteOffset: {   offset: integer } offset: an integer equal to a0-based offset from the beginning of the cleartext data for this media.

In one embodiment, the zone map associated with a track should beincluded as an ‘mZON’ box in a ‘udta’ container box in the ‘trak’ boxfor that track (for track-based media) or the ‘udta’ container box inthe Discrete Media headers box (for, e.g., OMA DCF media).

class MediaZoneMap( ) extends Box (‘mZON’) { uint(32) zoneMapDataSize;bit(8) zoneMapData[zoneMapDataSize]; }

Where:

“zoneMapData” refers to the binary encoding of the zone map (an exampleof which is described in more detail below).

“zoneMapDataSize” refers to the size of the binary encoding of the zonemap.

In one embodiment, for track-based audio-only presentations, the zonemap is included in the audio track, and for track-based audio+videopresentations, the zone map is included in the video track. Forbox-based presentations, the zone map is a descendent of the samecontainer as the one that contains the media data box for thepresentation to which the map corresponds.

In one embodiment, for media where the media data consists of accessunit samples, the mediaDigestValue for a zone is computed over the bytesequence made of all the sample data from the first sample to the lastsample of the zone (included). For media where the media data isrepresented by a single byte sequence (such as the ‘odda’ box in OMADCF), the mediaDigestValue for a zone is computed over the portion ofthe byte sequence between the start and the end of the zone.

APPENDIX B Binary Encoding IsoMediaAccessUnit: {   sample: unsigned int(32) } IsoMediaByteOffset: {   sample: unsigned int (64) }InternalZoneInfo: {  fromPoint: unsigned int (32)  toPoint: unsigned int(32)  id: unsigned int (32)  attributes: unsigned int (8) mediaDigestAlgorithm: unsigned int (8)  mediaDigestValue: {  mediaDigestValueDataSize: unsigned int (8)   mediaDigestValueData: bit(8) [mediaDigestValueDataSize]  }  meteringTag: {   meteringTagDataSize:unsigned int (8)

Although the foregoing has been described in some detail for purposes ofclarity, it will be apparent that certain changes and modifications maybe made within the scope of the appended claims. For example, whileseveral examples have been presented in the context of audio-visualcontent such a movies, it will be appreciate that the systems andmethods described herein are suitable for broader application, and canbe used in the context of virtually any type of electronic content. Forexample, without limitation, the systems and methods described hereincould be applied to audio content (e.g., a digitally recorded song, aradio broadcast, a podcast, etc.), textual content (e.g., an electronicbook or magazine, HTML content, a word processing document, etc.) wherethe various zones could be defined to include content such as copyrightinformation, advertisements, and the like, or any other suitableelectronic content. It should be noted that there are many alternativeways of implementing both the processes and apparatuses describedherein. Accordingly, the present embodiments are to be considered asillustrative and not restrictive, and the inventive body of work is notto be limited to the details given herein, but may be modified withinthe scope and equivalents of the appended claims.

1-20. (canceled)
 21. A method of packaging a first piece of electroniccontent, the method being performed on a system comprising at least oneprocessor, the method comprising: creating, using the processor, a firstzone map defining a plurality of zones, a first zone of the plurality ofzones being associated with at least a first portion of the first pieceof electronic content; and associating, by the processor, an electroniclicense with the first piece of electronic content, the electroniclicense comprising at least one control program, the electronic licensedefining one or more first conditions associated with access to or otheruse of the at least a first portion of the piece of electronic contenton a device; wherein the control program is configured to, when executedby the device, determine that a first predefined condition associatedwith the first zone is met and, after the first predefined condition ismet, to impose a first obligation on access to or use of the at least afirst portion of the first piece of electronic content.
 22. The methodof claim 21, wherein the plurality of zones further comprise a secondzone associated with at least a second portion of the first piece ofelectronic content, wherein the electronic license further defines oneor more second conditions associated with access to or other use of theat least a second portion of the piece of electronic content on thedevice, and wherein the control program is further configured todetermine that a second predefined condition associated with the secondzone is met and, after the second predefined condition is met, to imposea second obligation on access to or use of the at least a second portionof the first piece of electronic content.
 23. The method of claim 21,wherein the electronic license comprises code for removing the firstobligation after a second predefined condition is met.
 24. The method ofclaim 21, further comprising digitally signing the first zone map usinga first key configured to decrypt at least part of the first piece ofelectronic content.
 25. The method of claim 21, further comprising:calculating a hash value of a first key configured to decrypt at leastpart of the first piece of electronic content; and digitally signing thefirst zone map using the hash value.
 26. The method of claim 21, furthercomprising digitally signing the first zone map using a first keyderived from a second key configured to decrypt at least part of thefirst piece of electronic content.
 27. The method of claim 21, whereinthe first zone map further comprises a reference to at least oneexternal zone, the at least one external zone being associated with asecond piece of electronic content separate from the first piece ofelectronic content.
 28. The method of claim 27, wherein the second pieceof electronic content is associated with a second zone map, the secondzone map defining at least one zone in the second piece of electroniccontent.
 29. The method of claim 21, wherein the first obligation isassociated with a playback condition of the at least a first portion ofthe first piece of electronic content.
 30. The method of claim 29,wherein the playback condition comprises a condition associated with atleast one of playing, skipping, and fast-forwarding the at least a firstportion of the first piece of electronic content.
 31. The method ofclaim 21, wherein each of the plurality of zones is associated with atleast one zone identifier included in the first zone map.
 32. The methodof claim 31, wherein at least one zone of the plurality of zones isassociated with a plurality of zone identifiers included in the firstzone map.
 33. A non-transitory computer-readable storage medium storinginstructions that, when executed by a system comprising a processor,cause the system to perform a method of packaging a first piece ofelectronic content comprising: creating a zone map defining a pluralityof zones, a first zone of the plurality of zones being associated withat least a first portion of the first piece of electronic content; andassociating an electronic license with the first piece of electroniccontent, the electronic license comprising at least one control program,the electronic license defining one or more first conditions associatedwith access to or other use of the at least a first portion of the pieceof electronic content on a device; wherein the control program isconfigured to, when executed by the device, determine that a firstpredefined condition associated with the first zone is met and, afterthe first predefined condition is met, to impose a first obligation onaccess to or use of the at least a first portion of the first piece ofelectronic content.
 34. The non-transitory computer-readable storagemedium of claim 33, further comprising digitally signing the zone mapusing a first key configured to decrypt at least part of the first pieceof electronic content.
 35. The non-transitory computer-readable storagemedium of claim 33, wherein the method further comprises: calculating ahash value of a first key configured to decrypt at least part of thefirst piece of electronic content; and digitally signing the zone mapusing the hash value.
 36. The non-transitory computer-readable storagemedium of claim 33, wherein the method further comprises digitallysigning the zone map using a first key derived from a second keyconfigured to crypt at least part of the first piece of electroniccontent.
 37. The non-transitory computer-readable storage medium ofclaim 33, wherein the zone map further comprises a reference to at leastone external zone, the at least one external zone being associated witha second piece of electronic content separate from the first piece ofelectronic content.
 38. The non-transitory computer-readable storagemedium of claim 33, wherein the first obligation is associated with aplayback condition of the at least a first portion of the first piece ofelectronic content.
 39. The non-transitory computer-readable storagemedium of claim 33, wherein each of the plurality of zones is associatedwith at least one zone identifier included in the zone map.
 40. Thenon-transitory computer-readable storage medium of claim 39, wherein atleast one zone of the plurality of zones is associated with a pluralityof zone identifiers included in the zone map.